The “Payment Card Industry” (PCI) relates to the use of cards (e.g., debit cards, credit cards, prepaid cards, ATM cards, etc.) as substitutes for currency. Such cards often are used by cardholders for depositing and withdrawing funds from bank accounts, moving funds amongst accounts, as well as for purchases of products and/or services from vendors.
The Payment Card Industry Data Security Standard (PCI-DSS) is an information security standard designed to mitigate fraudulent use of PCI cards by imposing greater control over transmission and storage of cardholder data (e.g., primary account number or PAN, card validation code(s), personal identification number or PIN associated with a card). Exemplary elements of PCI-DSS include protecting and restricting access to stored cardholder data, tracking and monitoring all access to network resources and cardholder data, encrypting transmission of cardholder data across open or public networks, use and regular update of anti-virus software, installation and maintenance of a firewall configuration to protect cardholder data and, particularly in purchase and sale environments, avoiding vendor-supplied defaults for system passwords and other security parameters. Accordingly, PCI-DSS conventionally requires security protocols, including data encryption, to safeguard sensitive information associated with a PCI card and its holder.
Notwithstanding the various requirements of PCI-DSS, this standard does not necessarily provide for infallible data security; in particular, a system that handles information associated with a cardholder may nonetheless be vulnerable in some respects to breach even if deemed to be PCI-compliant. Moreover, PCI-DSS requirements may in some cases be burdensome, expensive to implement, and confusing to comply with due to subjective interpretations and enforcement. Additionally, compliance validation is required only for some types of vendors and may be optional for others (e.g., depending on the card brand).
“Tokenization” is the process of replacing sensitive information with a surrogate or “token” that is not considered to be sensitive and that masks the sensitive information that it replaces. Tokenization techniques can be employed with various types of sensitive information (e.g., payment information such as PCI card information/cardholder data, bank transactions, medical records, criminal records, vehicle driver information, loan applications, stock trading and voter registration, etc.). In the PCI environment, tokens conventionally are used to reference cardholder data that is stored in a database or computer system (e.g., a “tokenization system”) different than the database or computer system used by a merchant/vendor to store various information relating to customers and/or purchase transactions. Accordingly, tokenization has been employed to increase the security of electronic transactions, mitigate theft of cardholder data in storage, and facilitate merchant/vendor system compliance with PCI-DSS; in particular, tokens, rather than cardholder data, are stored in the merchant/vendor system.
Tokens may be formatted in a variety of ways. Some conventional tokenization systems generate tokens so as to match the format of the original sensitive data. For example, a token for PCI card information/cardholder data (hereafter “payment information”) may have a same length as the PAN, and may contain elements of the original PAN (e.g., the last four digits of the PAN). The token also may include alphanumeric characters that represent miscellaneous cardholder information and/or data specific to a particular purchase transaction.
When an authorization request is made (e.g., by a vendor to a payment system) to verify the legitimacy of a card used for a purchase transaction (and an available credit limit, if applicable), typically the actual payment information is used only in the initial authorization request, together with transaction details (e.g., purchase price). Pursuant to a conventional authorization and tokenization process, if an authorization request is approved, a token is returned to the requester (e.g., the vendor) instead of the payment information, and the payment information is encrypted and securely stored in the tokenization system. The token, instead of the payment information, is stored in the vendor's system in a customer record associated with the cardholder. Accordingly, a breach of the vendor's system does not expose the actual payment information to fraudulent use; more specifically, the token itself, if stolen, cannot be used for transactions or fraudulent charges. Once the vendor has received and stored the token, the vendor may use the token to authorize subsequent purchase transactions by the cardholder.